Application programs running acceptably at first can become poor performers after being executed over time because of various reasons including changes in the workload characteristics of the programs. For example, in the Java Runtime Environment (JRE), the Java Virtual Machine (JVM) relies on a dynamic optimizing compiler to speed up execution of Java applications. While the application runs, the JVM identifies the most frequently invoked methods, i.e., “hot” methods, optimizes them, and places the optimized methods in a code cache so that subsequent invocations of these methods are more efficient as the cached versions of the methods are used. Code cache is a designated area in memory that stores optimized code of hot methods. A set of hot methods is usually associated with a particular type of load or the set of actions performed by the program. A program running two different loads provides two different sets of hot methods. For example, a tax program when preparing tax for an individual is associated with a set of hot methods different from a set of hot methods associated with the same tax program preparing tax for a corporation because the methods preparing the tax for an individual are different from the methods preparing tax for a corporation. Consequently, hot methods are usually identified when there is change in the program load. As additional hot methods are identified and optimized, the application runs more efficiently. However, after the application runs for some time, the hot methods reach a steady state, i.e., no new hot methods can be identified. Application performance depends on how well the steady state methods are optimized.
Thresholds affecting the level and scope of application optimization are usually preset when the Java environment is shipped to customers. Both aggressive and conservative thresholds can lead to poor performance. For example, an aggressive threshold for a larger amount of code of a method to be inlined during compilation can cause excessive instruction cache (I-cache) misses, while a conservative threshold leaves larger portions of the code un-optimized. Both situations lead to poor application performance.
Typically, when a user recognizes a poorly performing application, the user examines the application, identifies the parameters in the JVM that affect application performance, and reassigns more suitable values to these parameters. However, for the new changes to be effective, a new environment based on the modified parameters must be installed, and this requires turning off the existing application. During the time the application is turned off, it cannot be used, resulting in business disruptions. In various situations, to correct the problem, the user is required to work with the business institution providing the Java environment. In these situations, the user has to be physically present at the site of the institution, where the application's software and hardware environments and the conditions leading to the poor performance would need to be reproduced, all of which could be very costly. In many situations, producing the conditions causing the poor performance is not easy. Further, after the application is debugged, the new Java environment is typically modified, the user then has to install the new Java environment including the modifications in the user's machine. This also requires that the application be turned off and results in disruptions as discussed above.
Based on the foregoing, it is desirable that mechanisms be provided to solve the above deficiencies and related problems.